פתיחת תובנות ביצועים: איסוף וצבירת נתונים באמצעות ה-_tracingMarker הניסיוני של React

בנוף המתפתח תמיד של פיתוח ווב, ביצועים הם לא רק תכונה; הם גורם מבדל קריטי. עבור אפליקציות שנבנו עם React, הבנה ואופטימיזציה של ביצועים הן בעלות חשיבות עליונה כדי לספק חווית משתמש חלקה ומרתקת. בעוד ש-React מציעה מזה זמן רב כלי מפתחים לניתוח ביצועים, התקדמויות ניסיוניות מהעת האחרונה מבטיחות לספק תובנות עמוקות עוד יותר. פוסט זה צולל לעולם המרגש, אם כי הניסיוני, של איסוף נתוני _tracingMarker וצבירת נתוני ביצועים בתוך React, ומציע פרספקטיבה גלובלית על הפוטנציאל והיישום שלו.

ההכרח בביצועים בעולם דיגיטלי גלובלי

עבור מפתחים המכוונים לקהל גלובלי, לא ניתן להפריז בחשיבות ביצועי האפליקציה. משתמשים ביבשות שונות, עם מהירויות אינטרנט, יכולות מכשיר ותנאי רשת משתנים, מצפים שהאפליקציות שלהם ייטענו במהירות ויגיבו באופן מיידי. אפליקציה איטית עלולה להוביל לתסכול משתמשים, שיעורי נטישה גבוהים, ובסופו של דבר, לאובדן הזדמנויות עסקיות. לכן, אסטרטגיות ניטור ואופטימיזציה חזקות של ביצועים הן חיוניות. React, כאחת מספריות ה-JavaScript הפופולריות ביותר לבניית ממשקי משתמש, ממלאת תפקיד מכריע במתן האפשרות למפתחים ליצור אפליקציות עם ביצועים גבוהים. הצגתן של תכונות ניסיוניות כמו _tracingMarker מסמנת מחויבות להעצמת יכולות אלו אף יותר.

הבנת כלי ניטור הביצועים של React: סקירה קצרה

לפני שנצלול לפרטים של _tracingMarker, כדאי לעבור בקצרה על יכולות ניטור הביצועים הקיימות של React. כלי המפתחים של React, תוסף דפדפן לכרום ולפיירפוקס, היוו כלי עזר משמעותי בסיוע למפתחים לנתח פרופילי רינדור של קומפוננטות, לזהות צווארי בקבוק ולהבין את מחזורי החיים של קומפוננטות. תכונות כמו לשונית ה-Profiler מאפשרות למפתחים להקליט אינטראקציות, לנתח זמני רינדור ולהמחיש את משכי הזמן של ה-commits. עם זאת, כלים אלה מספקים לעתים קרובות תמונות מצב ודורשים אינטראקציה ידנית כדי לאסוף נתונים עבור תרחישים ספציפיים. הצורך בנתוני ביצועים אוטומטיים, גרנולריים וניתנים לצבירה הפך ברור.

היכרות עם ה-_tracingMarker הניסיוני

ה-_tracingMarker הוא תכונה ניסיונית בתוך React שמטרתה לספק דרך סטנדרטית ותכנותית יותר למדוד ולאסוף נתוני ביצועים. הרעיון המרכזי שלו סובב סביב סימון נקודות ספציפיות בזרימת הביצוע של אפליקציית React. סמנים אלו יכולים לשמש למדידת משך הפעולות השונות, למעקב אחר תזמון אירועים, ובסופו של דבר, לצבור נתונים אלו לניתוח ביצועים מקיף.

מה מאפשר _tracingMarker?

• מדידה גרנולרית: מפתחים יכולים למקם סמנים סביב קטעי קוד ספציפיים, מתודות מחזור חיים של קומפוננטות, או לוגיקה מותאמת אישית כדי למדוד את זמן הביצוע שלהם במדויק.
• תזמון אירועים: הוא מאפשר תזמון של אירועים בדידים בתוך המערכת האקולוגית של React, כגון עדכוני state, בקשות רשת המופעלות על ידי קומפוננטות, או השלמת חישובים מורכבים.
• איסוף נתונים אוטומטי: בניגוד לסשנים ידניים של פרופיילינג, _tracingMarker מאפשר איסוף של נתוני ביצועים בזמן שהאפליקציה רצה, פוטנציאלית בסביבות ייצור (פרודקשן) (תוך שיקול דעת זהיר).
• פוטנציאל לצבירת נתונים: הנתונים המובנים הנאספים על ידי סמנים אלו מתאימים באופן אידיאלי לצבירה, ומאפשרים ניתוח של מגמות, זיהוי בעיות ביצועים נפוצות, והשוואה בין סשנים של משתמשים שונים או סביבות שונות.

כיצד _tracingMarker עובד מבחינה רעיונית?

בבסיסו, _tracingMarker פועל על ידי מינוף ממשקי API של ביצועי דפדפן, כגון High Resolution Time API או Performance Timeline API, או על ידי יישום מנגנוני תזמון משלו. כאשר נתקלים ב-_tracingMarker, הוא יכול לרשום זמן התחלה. כאשר סמן סיום תואם מושג, או שפעולה ספציפית מסתיימת, משך הזמן מחושב ונשמר. נתונים אלו נאספים בדרך כלל על ידי מערכת ניטור ביצועים.

טבעו הניסיוני של _tracingMarker אומר שממשק ה-API שלו ופרטי היישום עשויים להשתנות. עם זאת, העיקרון הבסיסי של מדידת קוד עם סמנים בעלי שם למדידת ביצועים נשאר עקבי.

אסטרטגיות איסוף נתונים עם _tracingMarker

האפקטיביות של _tracingMarker תלויה ביעילות איסוף נתוני הביצועים. הדבר כרוך במיקום אסטרטגי של סמנים ובמנגנון איסוף נתונים חזק.

מיקום אסטרטגי של סמנים

הכוח האמיתי של _tracingMarker נובע ממיקום מחושב. שקלו את התחומים הבאים:

• מחזורי רינדור של קומפוננטות: סימון ההתחלה והסוף של תהליך הרינדור של קומפוננטה יכול לחשוף אילו קומפוננטות לוקחות הכי הרבה זמן להתרנדר, במיוחד במהלך עדכונים. זה חיוני לזיהוי קומפוננטות המתרנדרות מחדש שלא לצורך. לדוגמה, בפלטפורמת מסחר אלקטרוני מורכבת עם רשימות מוצרים דינמיות, סימון הרינדור של כרטיסי מוצר בודדים יכול לאתר בעיות ביצועים במהלך חיפושים או החלת מסננים.
• אחזור ועיבוד נתונים: מדידת מחזור החיים של קריאות API, טרנספורמציות נתונים ועדכוני state הקשורים לאחזור נתונים יכולה להדגיש השהיות רשת או טיפול לא יעיל בנתונים. דמיינו אפליקציית הזמנת נסיעות שאוספת נתוני טיסות ממספר ממשקי API; סימון כל אחזור ושלב עיבוד הנתונים שלאחריו יכול לחשוף איזה API איטי או היכן עיבוד צד-הלקוח מהווה צוואר בקבוק.
• אינטראקציות משתמש: מדידת הזמן שלוקח לאינטראקציות משתמש קריטיות, כגון לחיצות על כפתורים, הגשת טפסים או שאילתות חיפוש, מספקת תובנה ישירה לגבי הביצועים הנתפסים על ידי המשתמש. באפליקציית מדיה חברתית, סימון הזמן החל מפרסום תגובה על ידי משתמש ועד להופעתה על המסך הוא מדד ביצועים חיוני.
• אינטגרציות צד-שלישי: אם האפליקציה שלכם מסתמכת על סקריפטים או ערכות SDK של צד-שלישי (למשל, לאנליטיקה, פרסום או צ'אט), סימון זמן הביצוע של אינטגרציות אלו יכול לסייע בבידוד ירידה בביצועים הנגרמת על ידי גורמים חיצוניים. זה חשוב במיוחד עבור אפליקציות גלובליות שעשויות לחוות תנאי רשת משתנים עבור משאבי צד-שלישי.
• לוגיקה עסקית מורכבת: עבור אפליקציות עם לוגיקה חישובית כבדה, כגון כלי מידול פיננסי או פלטפורמות להדמיית נתונים, סימון ביצוע בלוקי הלוגיקה המרכזיים הללו חיוני להבנה ואופטימיזציה של ביצועים חישוביים.

איסוף הנתונים

לאחר שהסמנים ממוקמים, יש לאסוף את הנתונים. ניתן להשתמש במספר גישות:

• כלי מפתחים בדפדפן: לפיתוח וניפוי שגיאות מקומיים, כלי המפתחים בדפדפן (כמו לשונית ה-Performance ב-Chrome DevTools) יכולים לעתים קרובות לפרש ולהציג נתונים ממנגנוני המעקב הניסיוניים של React, ומספקים משוב חזותי מיידי.
• רישום מותאם אישית: מפתחים יכולים ליישם פתרונות רישום מותאמים אישית כדי ללכוד את נתוני הסמנים ולשלוח אותם לקונסול או לקובץ מקומי לצורך ניתוח במהלך הפיתוח.
• שירותי ניטור ביצועים (PMS): עבור סביבות ייצור, אינטגרציה עם שירות ניטור ביצועים ייעודי היא הגישה המדרגית והיעילה ביותר. שירותים אלה מיועדים לאסוף, לצבור ולהמחיש נתוני ביצועים ממספר גדול של משתמשים ברחבי העולם. דוגמאות כוללות את Sentry, Datadog, New Relic, או פתרונות מותאמים אישית שנבנו עם כלים כמו OpenTelemetry.

בעת אינטגרציה עם PMS, הנתונים שנאספו על ידי _tracingMarker יישלחו בדרך כלל כאירועים מותאמים אישית או כ-spans, מועשרים בהקשר כגון מזהה משתמש, סוג מכשיר, דפדפן ומיקום גיאוגרפי. הקשר זה חיוני לניתוח ביצועים גלובלי.

צבירת נתוני ביצועים: הפיכת נתונים גולמיים לתובנות מעשיות

נתוני ביצועים גולמיים, אף שהם אינפורמטיביים, לעיתים קרובות מציפים. הערך האמיתי מופיע כאשר נתונים אלה נצברים ומנתחים כדי לחשוף מגמות ודפוסים. צבירת נתוני ביצועים עם _tracingMarker מאפשרת הבנה עמוקה יותר של התנהגות האפליקציה בקרב פלחי משתמשים וסביבות מגוונות.

מדדי צבירה מרכזיים

בעת צבירת נתונים שנאספו באמצעות _tracingMarker, התמקדו במדדים המרכזיים הבאים:

• משך זמן ממוצע וחציוני: הבנת הזמן הטיפוסי שלוקח לפעולה מספקת קו בסיס. החציון הוא לעתים קרובות עמיד יותר לחריגים מאשר הממוצע.
• אחוזונים (לדוגמה, 95, 99): מדדים אלה חושפים את הביצועים שחווים הפלחים האיטיים ביותר של בסיס המשתמשים שלכם, ומדגישים בעיות קריטיות פוטנציאליות המשפיעות על מיעוט משמעותי.
• שיעורי שגיאות הקשורים לפעולות: קישור בין סמני ביצועים לשגיאות יכול לאתר פעולות שאינן רק איטיות אלא גם נוטות להיכשל.
• התפלגות משכי זמן: הדמיית התפלגות התזמונים (למשל, באמצעות היסטוגרמות) מסייעת לזהות אם הביצועים טובים באופן עקבי, או אם קיימת שונות רחבה.
• פילוח ביצועים גיאוגרפי: עבור קהל גלובלי, צבירת נתוני ביצועים לפי אזור או מדינה היא חיונית. זה יכול לחשוף בעיות הקשורות לביצועי CDN, קרבת שרתים, או תשתית אינטרנט אזורית. לדוגמה, אפליקציה עשויה לפעול בצורה מושלמת בצפון אמריקה אך לסבול מהשהיה גבוהה בדרום מזרח אסיה, מה שמדגיש צורך באספקת תוכן טובה יותר או פריסת שרתים אזורית.
• פילוח לפי סוג מכשיר ודפדפן: למכשירים שונים (מחשבים שולחניים, טאבלטים, ניידים) ולדפדפנים יש מאפייני ביצועים משתנים. צבירת נתונים לפי גורמים אלה מסייעת להתאים אופטימיזציות. אנימציה מורכבת עשויה לפעול היטב על מחשב שולחני חזק אך להוות גורם משמעותי לפגיעה בביצועים במכשיר נייד בעל הספק נמוך בשוק מתפתח.
• ביצועים לפי פלחי משתמשים: אם אתם מפלחים את המשתמשים שלכם (למשל, לפי רמת מנוי, תפקיד משתמש או רמת מעורבות), ניתוח ביצועים עבור כל פלח יכול לחשוף בעיות ספציפיות המשפיעות על קבוצות משתמשים מסוימות.

טכניקות צבירה

ניתן להשיג צבירה באמצעים שונים:

• צבירה בצד השרת: שירותי ניטור ביצועים בדרך כלל מטפלים בצבירה בצד האחורי שלהם. הם מקבלים נקודות נתונים גולמיות, מעבדים אותן, ומאחסנים אותן בפורמט שניתן לשאול.
• צבירה בצד הלקוח (בזהירות): בתרחישים מסוימים, צבירה בסיסית (כמו חישוב ממוצעים או ספירות) עשויה להתבצע בצד הלקוח לפני שליחת הנתונים כדי להפחית את תעבורת הרשת. עם זאת, יש לעשות זאת בשיקול דעת כדי למנוע פגיעה בביצועי האפליקציה עצמה.
• מחסני נתונים וכלי בינה עסקית (BI): לניתוח מתקדם, ניתן לייצא נתוני ביצועים למחסני נתונים ולנתח אותם באמצעות כלי BI, מה שמאפשר קורלציות מורכבות עם מדדים עסקיים אחרים.

דוגמאות מעשיות ומקרי שימוש (פרספקטיבה גלובלית)

בואו נבחן כיצד ניתן ליישם _tracingMarker וצבירת נתונים בתרחישים גלובליים בעולם האמיתי:

דוגמה 1: אופטימיזציה של תהליך התשלום במסחר אלקטרוני

תרחיש: פלטפורמת מסחר אלקטרוני גלובלית חווה ירידה בשיעורי ההמרה במהלך תהליך התשלום. משתמשים באזורים שונים מדווחים על רמות ביצועים משתנות.

יישום:

• מקמו _tracingMarker סביב שלבים מרכזיים: אימות פרטי תשלום, אחזור אפשרויות משלוח, עיבוד ההזמנה ואישור הרכישה.
• אספו נתונים אלה, יחד עם המיקום הגיאוגרפי של המשתמש, סוג המכשיר והדפדפן.

צבירה ותובנות:

• צברו את משך הזמן של הסמן 'אחזור אפשרויות משלוח'.
• תובנה: הניתוח מגלה שמשתמשים באוסטרליה ובניו זילנד חווים עיכובים ארוכים משמעותית (למשל, אחוזון 95 > 10 שניות) בהשוואה למשתמשים בצפון אמריקה (חציון < 2 שניות). זה יכול להיות בגלל מיקום שרת ה-API של המשלוחים או בעיות CDN באותו אזור.
• פעולה: חקרו את מנגנון ה-caching של ה-CDN עבור אפשרויות משלוח באזור APAC, או שקלו שותפי/שרתי משלוח אזוריים.

דוגמה 2: שיפור תהליך קליטת משתמשים (Onboarding) באפליקציית SaaS

תרחיש: חברת תוכנה כשירות (SaaS) מבחינה שמשתמשים בשווקים מתעוררים נוטשים במהלך זרימת הקליטה הראשונית, הכוללת הגדרת העדפות ואינטגרציה עם שירותים אחרים.

יישום:

• סמנו את הזמן שלוקח לכל שלב באשף הקליטה: יצירת פרופיל משתמש, ייבוא נתונים ראשוני, הגדרת אינטגרציה (למשל, חיבור לשירות אחסון ענן), ואישור תצורה סופי.
• כמו כן, סמנו את הביצועים של מודולי האינטגרציה הספציפיים.

צבירה ותובנות:

• צברו את משך הזמן של 'הגדרת אינטגרציה' לפי מדינת המשתמש וסוג האינטגרציה.
• תובנה: הנתונים מראים שמשתמשים בחלקים של דרום אמריקה ואפריקה מתקשים באינטגרציה עם ספק אחסון ענן מסוים, עם שיעורי כישלון גבוהים יותר וזמנים ארוכים יותר. זה עשוי לנבוע מחוסר יציבות ברשת או מביצועי API אזוריים של אותו ספק.
• פעולה: ספקו אפשרויות אינטגרציה חלופיות לאזורים אלה או הציעו טיפול בשגיאות ומנגנוני ניסיון חוזר חזקים יותר עבור האינטגרציה הספציפית.

דוגמה 3: אופטימיזציה של טעינת תוכן בפלטפורמת חדשות גלובלית

תרחיש: אתר חדשות שואף להבטיח זמני טעינת מאמרים מהירים לקוראים ברחבי העולם, במיוחד במכשירים ניידים עם רוחב פס מוגבל.

יישום:

• סמנו את טעינת תוכן המאמר הראשי, תמונות בטעינה עצלה (lazy-loaded), פרסומות ומאמרים קשורים.
• תייגו נתונים עם סוג מכשיר (נייד/שולחני) ומהירות רשת משוערת היכן שניתן להסיק זאת.

צבירה ותובנות:

• צברו את משך טעינת 'תמונות בטעינה עצלה' עבור משתמשים ניידים באזורים עם מהירויות אינטרנט נמוכות מדווחות.
• תובנה: האחוזון ה-99 לטעינת תמונות גבוה באופן מוגזם עבור משתמשים ניידים בדרום מזרח אסיה, מה שמצביע על אספקת תמונות איטית למרות שימוש ב-CDN. הניתוח מראה שמוגשים פורמטי תמונה לא מותאמים או קבצים בגדלים גדולים.
• פעולה: ישמו דחיסת תמונות אגרסיבית יותר, השתמשו בפורמטי תמונה מודרניים (כמו WebP) היכן שנתמך, ובצעו אופטימיזציה של תצורות ה-CDN עבור אותם אזורים.

אתגרים ושיקולים

בעוד ש-_tracingMarker מציע אפשרויות מרגשות, חיוני להיות מודעים לאתגרים ולשיקולים הקשורים לטבעו הניסיוני ולאיסוף נתוני ביצועים:

• סטטוס ניסיוני: כתכונה ניסיונית, ה-API נתון לשינויים או הסרה בגרסאות עתידיות של React. מפתחים המאמצים אותו צריכים להיות מוכנים לשינויי קוד פוטנציאליים (refactoring).
• תקורה בביצועים: מדידת קוד, גם עם מנגנונים יעילים, יכולה להוסיף תקורה קטנה בביצועים. זה קריטי במיוחד עבור סביבות ייצור. נדרשות בדיקות יסודיות כדי להבטיח שהמדידה עצמה לא פוגעת בחוויית המשתמש.
• נפח נתונים: איסוף נתונים גרנולריים מבסיס משתמשים גדול יכול לייצר כמויות אדירות של נתונים, מה שמוביל לעלויות אחסון ועיבוד. אסטרטגיות צבירה ודגימה יעילות הן חיוניות.
• חששות פרטיות: בעת איסוף נתוני ביצועים ממשתמשים, במיוחד בייצור, יש להקפיד על תקנות פרטיות (כמו GDPR, CCPA). יש לאנונימיזציה של הנתונים ככל האפשר, ויש ליידע את המשתמשים על איסוף הנתונים.
• מורכבות הצבירה: בניית צינור חזק לצבירה וניתוח נתונים דורשת מאמץ הנדסי ומומחיות משמעותיים. מינוף פתרונות ניטור ביצועים קיימים הוא לעתים קרובות מעשי יותר.
• פירוש נכון של הנתונים: נתוני ביצועים יכולים לפעמים להיות מטעים. חיוני להבין את ההקשר, לבצע קורלציה עם מדדים אחרים, ולהימנע מהסקת מסקנות נמהרות. לדוגמה, משך סמן ארוך עשוי לנבוע מפעולה סינכרונית הכרחית, אם כי איטית, ולא בהכרח מפעולה לא יעילה.
• שונות ברשת הגלובלית: צבירת נתונים גלובלית פירושה התמודדות עם תנאי רשת שונים בתכלית. מה שנראה כפעולת צד-לקוח איטית עשוי להיות השהיית רשת. הבחנה ביניהם דורשת מדידה וניתוח זהירים.

שיטות עבודה מומלצות לאימוץ _tracingMarker

למפתחים המעוניינים למנף את הפוטנציאל של _tracingMarker, שקלו את השיטות המומלצות הבאות:

• התחילו באופן מקומי: התחילו להשתמש ב-_tracingMarker בסביבת הפיתוח שלכם כדי להבין את יכולותיו ולהתנסות במיקום סמנים.
• תעדפו אזורים מרכזיים: התמקדו במדידה של זרימות משתמש קריטיות ונקודות כאב ידועות בביצועים במקום לנסות לסמן הכל.
• פתחו אסטרטגיית נתונים: תכננו כיצד הנתונים שנאספו יאוחסנו, יצטברו וינתחו. בחרו שירות ניטור ביצועים מתאים או בנו פתרון מותאם אישית.
• נטרו את התקורה: מדדו באופן קבוע את השפעת המדידה שלכם על הביצועים כדי להבטיח שהיא לא פוגעת בחוויית המשתמש.
• השתמשו בשמות משמעותיים: תנו לסמנים שלכם שמות ברורים ותיאוריים המשקפים במדויק את מה שהם מודדים.
• ספקו הקשר לנתונים: אספו תמיד הקשר רלוונטי (user agent, מיקום, סוג מכשיר, גרסת דפדפן) לצד מדדי הביצועים.
• בצעו איטרציות ושיפורים: אופטימיזציית ביצועים היא תהליך מתמשך. נתחו ברציפות את הנתונים המצטברים שלכם ושפרו את המדידה שלכם ככל שהאפליקציה שלכם מתפתחת.
• הישארו מעודכנים: עקבו אחר מפת הדרכים של התכונות הניסיוניות והתיעוד של React לקבלת עדכונים ושינויים ב-_tracingMarker.

העתיד של ניטור ביצועים ב-React

הפיתוח של תכונות כמו _tracingMarker מסמן את המחויבות המתמשכת של React להעצים מפתחים עם תובנות ביצועים מתוחכמות. ככל שתכונות אלו יתבגרו וישתלבו יותר בליבת הספרייה או בכלי המפתחים, אנו יכולים לצפות ל:

• ממשקי API סטנדרטיים: ממשקי API יציבים וסטנדרטיים יותר למדידת ביצועים, מה שיהפוך את האימוץ לקל ואמין יותר.
• כלי מפתחים משופרים: אינטגרציה עמוקה יותר עם כלי המפתחים של React, שתאפשר הדמיה וניתוח אינטואיטיביים יותר של נתוני המעקב.
• מדידה אוטומטית: האפשרות שהיבטי ביצועים מסוימים יימדדו אוטומטית על ידי React עצמה, מה שיפחית את המאמץ הידני הנדרש מהמפתחים.
• תובנות מבוססות בינה מלאכותית: פתרונות ניטור ביצועים עתידיים עשויים למנף בינה מלאכותית כדי לזהות באופן אוטומטי אנומליות, להציע אופטימיזציות ולחזות בעיות ביצועים פוטנציאליות על בסיס נתונים מצטברים.

עבור קהילת מפתחים גלובלית, התקדמויות אלו משמעותן כלים חזקים יותר להבטחת ביצועים אופטימליים של אפליקציות עבור כל משתמש, ללא קשר למיקומו או למכשירו. היכולת לאסוף ולצבור נתוני ביצועים מפורטים באופן תכנותי היא צעד משמעותי לקראת בניית אפליקציות גלובליות רספונסיביות ובעלות ביצועים גבוהים באמת.

סיכום

ה-_tracingMarker הניסיוני של React מייצג חזית מבטיחה בניטור ביצועים, ומציע פוטנציאל לאיסוף נתונים גרנולרי וצבירה מתוחכמת. על ידי מיקום אסטרטגי של סמנים ויישום אסטרטגיות חזקות לאיסוף וניתוח נתונים, מפתחים יכולים להשיג תובנות יקרות ערך לגבי ביצועי האפליקציה שלהם בקרב בסיסי משתמשים גלובליים מגוונים. אמנם עדיין ניסיוני, הבנת עקרונותיו ויישומיו הפוטנציאליים היא חיונית לכל מפתח השואף לספק חוויות משתמש יוצאות דופן בעולם הדיגיטלי המחובר של ימינו. ככל שתכונה זו תתפתח, היא ללא ספק תהפוך לכלי חיוני בארסנל של מפתחי React מודעי-ביצועים ברחבי העולם.

כתב ויתור: _tracingMarker הוא תכונה ניסיונית. ממשק ה-API והתנהגותו עשויים להשתנות בגרסאות עתידיות של React. יש לעיין תמיד בתיעוד הרשמי של React לקבלת המידע המעודכן ביותר.